home *** CD-ROM | disk | FTP | other *** search
/ Sprite 1984 - 1993 / Sprite 1984 - 1993.iso / src / machserver / Todo < prev   
Text File  |  1992-11-16  |  13KB  |  250 lines
  1. Figure out where the time is going when you run the Andrew benchmark.
  2. - Figure out where the "system call" overhead is coming from.  Hang a
  3.   struct off the PCB to record various time intervals between receipt
  4.   of message and start of processing?  (Plus something similar for
  5.   message return.)  Verify that gettimeofday() really involves a
  6.   server call for UX.
  7.   - Write some dummy Sprite calls that are special-cased (e.g., have
  8.     the input thread send the reply; have a server thread send the
  9.     reply w/o the usual Sprite call processing).
  10.     - verify things work as they're supposed to.  Take out debug printfs.
  11.     - get comparison perf numbers.
  12.     - check in changes, including new syscall benchmark program.
  13.   - Write some dummy Sprite calls with 0, 1, 2, and 3 int arguments.
  14.     The calls should immediately return (i.e., don't even go through
  15.     the standard syscall overhead).  What is the perf overhead of
  16.     the different numbers of arguments?  [probably minimal]
  17.   - Could solve the pcb reclamation problem by using no-senders
  18.     notification to tell when to reap a dead pcb?  This would
  19.     hopefully let you have a pool of syscall threads and get rid of a
  20.     context switch.
  21. - Where is the rest of the exec() time going?
  22. - Where is rest of fork() time going?
  23.  
  24. Run the Andrew benchmark on native Sprite, on the Sprite server, and
  25. using the UX server.
  26. - rpc stats?
  27. - net stats:
  28.   - number of dropped broadcast packets that we sent
  29.   - bytes copied to make output packet contiguous for Mach's sake
  30.   - bytes sent?
  31.   - loopback packets
  32. - Make sure you haven't left junk lying around
  33.   /sprite/src/benchmarks/itc.
  34.  
  35. Fix the sprited exec to reuse the heap and swap segments.  Check
  36. performance gain.
  37.  
  38. Think about adding "inline" FS read/write stubs; have read() and
  39. write() use them (except maybe for whole-page page-aligned transfers).
  40. Check performance improvement.  Also hack stdio to page-align its
  41. buffers?  One problem: FS_USER is set at open time, not at I/O time.
  42.  
  43. See if you get a noticeable performance improvement by dynamically
  44. allocating the page-in buffer and turning on the dealloc flag to
  45. memory_object_data_supply.
  46.  
  47. Make sure the Sprite external pager does the right thing w.r.t.
  48. shadow pages.  (See the mail from Joe Barrera in +emacs ("Re:
  49. implementation of copy on write").)  This would probably only be an
  50. issue once you really wanted to do copy-on-write using an external
  51. pager.
  52.  
  53. Get control programs working with sprited.
  54. - rpccmd (timing control)
  55.  
  56. Hack the gdb "thread-list" command to include the MachID?
  57.  
  58. Upgrade anarchy (running Mach) to the 2.1 compiler, so that it's
  59. running the same stuff that Sprite has?  Should get 2.1 copies of
  60. ccom, uopt, ugen, as0, as1, crt0 (?), ld, nm, strip, and size.  Need
  61. to set links for them and for ccom, ugen, and as1.
  62.  
  63. Change sprited build environment to use "dsmach" machine type?
  64. - Convert your user-program build environment to use it.  
  65.   - Fix files in /sprite/lib/pmake.
  66. - Put the binaries in /sprite/cmds rather than in ~/cmds.sprited.  
  67. - Convert build environment for sprited.
  68.  
  69. Try to get the IP server running with sprited?
  70.  
  71. Think about fixing the Mach kernel so that emulate_fpa returns an
  72. exception code for unimplemeneted op codes, rather than calling
  73. kdb_trap directly.  Once you get this working, also think about
  74. plugging the Sprite ds3100 softfp.o into Mach.
  75.  
  76. More FS tests:
  77. - verify that file inheritance across fork works.  See
  78.   /sprite/src/tests/syscalls/fork.
  79. - verify that close-on-exec files are in fact closed.
  80. - Any other interesting tests from /sprite/src/tests (e.g.,
  81.   syscalls/{exit,fork})?
  82.  
  83. Make a list of unresolved design issues (and resolved issues that
  84. should still be reviewed in a Sprite meeting).
  85. - unresolved: some aspects of block devices (look for XXX in
  86.   callsDev); ScsiTape function pointers.
  87. - should review: net & dev modules; process destruction/message
  88.   handling synch.
  89. Let JO know when you'd like to make presentations on various subjects.
  90.  
  91. Try to clean up sprited VM design so that there is only one segment
  92. type, with behavioral flags (e.g., read-only, map-file-backwards).
  93. You may want to introduce a copy-on-fork flag.  Make sure you update
  94. Vm_Fork.
  95. - Will you also need to clean up the FS code so that it doesn't know
  96.   about the different segment types?  (See, e.g., Fs_PageRead.)
  97. - Another thing to consider is error recovery.  For shared files, you
  98.   can just pass the error codes back up to the user program.  For swap
  99.   files, you probably want to try harder to hide errors.
  100. - Make the stack segment per-process instead of per-task.
  101. - Fix Vm_MappedSegment so that arbitrary pages of the file can be
  102.   mapped at arbitrary places?  Is there code that might free
  103.   pages it shouldn't because of the overly general information in
  104.   Vm_MappedSegment?  Maybe you should just fix it to use
  105.   vmOps.c:UnmapPages.
  106. - This might also be a good time to separate the VM request threads
  107.   from Proc_ServerProc's.
  108. - Maybe segment destruction should be changed so that when the
  109.   segment's reference count goes to 0, you just clean it.  If the
  110.   reference count is still 0 when you get the lock_completed call,
  111.   then you can destroy it.  The hoped-for advantage is to reduce the
  112.   number of times a process has to wait for a DYING segment to get
  113.   cleaned before the process can map a particular file.  See notes
  114.   from 3-Feb-1992.
  115. - Need change the way code segments are handled, so that a process can
  116.   write into a private copy (for breakpoints) without affecting other
  117.   processes.  Give each process its own code segment?  (This would
  118.   break the one segment <-> one swap file mapping.)  Use the object
  119.   file as the "init" file instead of the swap file?
  120.  
  121. Review the callsVm, newVm, and changes lists (in machMerge).  
  122. Other possible cleanups:
  123. - Think about the following setup for making signal delivery more
  124.   reliable: Map a page for each process into the server's address
  125.   space; this yields cheaper communication with the emulation library.
  126.   Fix the emulation library to set a flag whenever it does a Mach call
  127.   (it might take some work to find all the instances).  Fix the server
  128.   so that it forces the user process to take delivery of the signal
  129.   except when that flag is set.  Add another flag to the mapped area
  130.   for the server to tell the emulation library that a signal is
  131.   pending.
  132. - Think about how to handle segments that aren't successfully mapped.
  133.   You'd like to distinguish the case where the segment is broken
  134.   (e.g., has a text length of 0, see 29-Nov-1991 notes) from the case
  135.   where a user specified bogus arguments.  Note that the current code
  136.   leaves the control port as null, which is bad because it leaves you
  137.   open to races with the kernel.  Maybe you could mark the control
  138.   port as dead and just leave it lying around until the kernel decides
  139.   to get rid of it?
  140. - Use Mach header files instead of local declarations (e.g., mach_msg,
  141.   timer stuff).
  142. - Is there a race in the exception handling code?  What happens if
  143.   Mach doesn't detect the exception (e.g., a floating point exception)
  144.   until after the process has made a Sprite request?
  145. - Look through the Sprite kernel log for fixes that you should take into
  146.   sprited (e.g., suspend/resume race?).
  147. - Fix catch_exception_raise to use SigMach_ExceptionString.
  148. - Fix mach_error_string (in libmach) to know about device error codes.
  149.   Send fixes back to CMU.  [Already done: MK73.]
  150. - Use MIG_DESTROY_REQUEST instead of MIG_NO_REPLY to indicate the the
  151.   sys module should eat the reply message?  (Requires MK73 or later.)
  152. - Remove "out of memory" panics in sprited?  Note that
  153.   maxBuffersAlloc is probably way too conservative; make it smaller.
  154.   numBuffersAlloc gets up to 40 with the processTree test.
  155. - Take Ken's fix to Compat_MapCode (see his bug report from
  156.   19-Dec-1991).
  157. - Think about calling Proc_Kill directly in some cases (rather than
  158.   doing a SIG_KILL), so that more specific information about the
  159.   failure (e.g., PROC_BAD_STACK) can be recorded.
  160. - Put the ckalloc stuff into /sprite/src/lib/c?  Probably want to
  161.   split Db routines from simple ck routines and then add a runtime
  162.   (or link time?) check to ensure that only one is used.
  163. - Figure out what to do about I/O errors in pager code.  For example,
  164.   can address fault in copyin/copyout if the file server returns an
  165.   error.  Should either (a) set the thread exception port to protect
  166.   code that accesses user space or (b) set the task exception port
  167.   (once) and set a flag in the PCB when accessing user addresses.
  168.   Need to do this in such a way that it won't interfere with using
  169.   gdb.  Also, still need some way to bail out--longjmp?
  170. - remove unused function declarations from fs header files & unixStubs
  171.   header files.
  172. - get rid of the asynch parameter to NetMachOutput, Net_Output, etc.
  173. - clean up error handling; just use ReturnStatus everywhere (or
  174.   reimplement ReturnStatus as a series of systems under Mach).
  175. - clean up error handling in memory_object_data_request: return
  176.   something more specific than just FAILURE or FS_INVALID_ARG.
  177. - Implement the Proc_SetPriority syscall, and re-enable the code in pmake
  178.   that uses it.
  179. - Are there any places left where Proc_MakeReady needs to wake up a
  180.   process that's waiting on an arbitrary condition variable?  (This
  181.   corresponds to native Sprite code that sticks the process into the
  182.   ready queue using some sync/sched back door.)
  183. - Fix naming conflicts with "mig".  Use "matchmaker" for things
  184.   related to Mach's MIG?
  185. - Try to fix the stdio package so that if the open in the init program
  186.   fails (somebody in libc wants to print a message), the system won't
  187.   just hang.
  188. - Fix sysPrintf.c so that server printf's go to the syslog device.
  189.   [already done?]
  190. - Figure out why if you start up a "cat /dev/syslog" and then kill it,
  191.   it doesn't die until it gets more syslog output.  Does this have
  192.   anything to do with the fact that server printf's don't currently go
  193.   to /dev/syslog?
  194. - put back the SetTimeOfDay call in Rpc_Start?
  195. - Once the packet filter has access to the correct header information,
  196.   fix it to not allow the host's own broadcast packets.
  197. - verify that umask works right.
  198. - Fix the user sleep() so that ps shows that the process is sleeping.
  199. - see why on a sun3, if DoExec aborts the client thread after calling
  200.   SetupVM, the server receives an EXC_EMULATION exception before the
  201.   client thread has even been resumed.  (See Richard Draves's and Dave
  202.   Black's messages "Re: suitability of thread_abort for exec" in
  203.   +mach.)  Note: this may be a kernel bug that's fixed in a more
  204.   recent kernel release (didn't they make a bunch of changes w.r.t.
  205.   AST's?)  At any rate, if you can't boot a recent kernel on Oregano
  206.   and the problem isn't reproducible on Anarchy, it's probably not
  207.   worth messing with.
  208. - use PROC_TERM_VANISHED as the termination reason when we find that a
  209.   process's task or thread has mysteriously disappeared.
  210. - decouple PROC_NO_MORE_REQUESTS from setting the termination
  211.   reason/status/code.
  212. - fix Compat_MapCode to understand the latest set of Sprite status
  213.   values. 
  214. - Be better about NULL versus NIL (to be more compatible with native
  215.   Sprite code).
  216. - use the Mach sys_errlist (for strerror).
  217. - Come up with some sort of registration scheme for "never-say-die"
  218.   server threads (e.g., network input, timer).  This way the shutdown
  219.   code doesn't have to wait quite so long before bailing out (compare
  220.   the number of remaining processes with the number of "never-say-die"
  221.   threads and exit if they're the same).
  222. - when setting up a network receive port, should also take inet packets.
  223. - rename Utils_MapMachStatus to Compat_MapMachStatus.
  224. - implement support for mmap().  Test Vm_CleanupSharedFile (open a
  225.   file, mmap it, make some changes, and close it.  Should be unable to
  226.   refer to the mapped memory any longer, and verify that the changes
  227.   made it out to the file server).
  228. - May want to hack DoWait to periodically wake up the parent, in case
  229.   a process gets blown away by Mach and we never find out.
  230.  
  231. Think about changing spriteTypes.defs to use c_string (see "MK Version
  232. MK59" in +mach3).
  233.  
  234. Investigate the version of gdb 4 that has Mach support.
  235.  
  236. Fix mips gdb bugs, at least for version running on Mach.
  237. - does poor job of recognizing static symbols.  For example,
  238.   can't set breakpoint for static function until have gotten the
  239.   symbols for the function's file.
  240. - stack backtrace sometimes goes on forever past __start.  
  241.   - Compare PC with PC at previous level and stop if the same?
  242. - backtrace doesn't go past emulator (e.g., for abort()).
  243. - should "realclean" or "distclean" remove the machid files?
  244. - Any fixes to Makefile.dist needed for new files (e.g., list of files
  245.   to make tags for)?
  246.  
  247. Fix /bin/passwd on Anarchy (running Mach).  ("passwd -l" drops core.)
  248. Try the 4.3 Reno passwd?
  249.  
  250.